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1 Introduction 

1 .1 Purpose of this Document 

This document provides the development guidelines for the implementation of an ARS Server for the 
MOTOTRBO radio system. 

1.2 Scope of this Document 

The MOTOTRBO subscriber has a number of data applications, such as Text Message, Telemetry 
and Location that require sending data messages asynchronously to a Subscriber Unit (SU). An 
efficient transmission of such data messages requires the SU to announce its availability. In order to 
reduce complexity and promote the efficient use of the air interface bandwidth, it is logical to add a 
single registration service that can be performed once and be used by all applications. The Automatic 
Registration Service (ARS) provides the common registration service. It accepts, stores, and 
distributes subscriber’s presence information to interested data applications. 

This document describes the specification of the ARS protocol and provides the architecture of the 
MOTOTRBO™ ARS. This includes detail on the format of the ARS protocol, as well as the 
functionality of the protocol commands and responses. Both the MOTOTRBO portable and mobile 
radios support the ARS protocol. 

1.3 Assumptions 

The reader of the document is assumed have the following domain knowledge: 

• Principles of two-way radio communications 

• Transmission Control Protocol (TCP) 

• User Datagram Protocol (UDP) 

• Internet Protocol (IP) 

The reader of the document is also assumed to have the DMR Association membership. The 
implementation of the AES encryption in the application is required to refer to one of the DMR 
Association standards called “DES/AES Encryption for DMR”. Only the DMR Association members 
have the right to access this document. 
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1.4 Abbreviations and Terms 



Abbreviation 


Term 1 


ACK 


Acknowledgement 


ARS 


Automatic Registration Service 


CPS 


Customer Programming Software 


DDMS 


Device Discovery & Mobility Service 


NACK 


Negative Acknowledgement 


NAT 


Network Address Translation 


SU 


Subscriber Unit 


RNI 


Radio Network Infrastructure 



1.5 Phrases and Definitions 



Phrase 


Definition 


ARS Enabled 


Enables the ARS feature. This feature allows the Subscriber Unit (SU) to register and 
receive query from the ARS server. 


ARS Refresh 
Timer 


Controls the periodic re-registration that the ARS client performs in order to keep the 
ARS registration updated between the radio and the ARS server. When this timer 
expires the ARS client sends a registration message. This timer restarts when the 
ARS client receives a registration acknowledgement from the ARS server. The 
duration of this timer is provided by the ARS server Acknowledgement Response. 


ARS Retry 
Timer 


Period of time the ARS client wait for subsequent ARS registration procedures. When 
the registration fails, this timer will start counting until a new registration procedure 
occurs. 


Capacity 

Plus 


A digital trunking system configuration accommodating an increased subscriber base 
and increased volumes of data 



1.6 References 

[1] MOTOTRBO Text Messaging ADK Guide 

[2] MOTOTRBO Location Data ADK Guide 

[3] MOTOTRBO Telemetry ADK Guide 

[4] MOTOTRBO Data Services Overview 

[5] MOTOTRBO Device Discovery and Mobility Service-to-Watcher Interface Protocol Specification 

[6] MOTOTRBO System Planner 

[7] Network Interface Service ADK Guide 
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2 ARS Overview 
2.1 ARS Architecture 

The figure below shows an architecture diagram for a simple configuration of ARS. The ARS consists 
of two components - a Registration Application in MOTOTRBO™ radio and an ARS Server in 
customer network. The ARS server is running on a device that is IP capable and can communicate 
with radio. The device is connected to a Radio via USB, which is called the ARS Radio. The ARS 
Radio is responsible for routing the IP message sent from/to the ARS Server. The transport layer 
between the MOTOTRBO™ radio and the ARS Server is UDP/IP. 



1 . Subscription 



2. Registration 




Figure 2-1 - ARS Architecture 

While powering on, roaming to another site, switching to a data capable mode, and occurring 
periodically, the Registration application in the SU sends a registration message to the ARS Server. It 
also sends a Deregistration message during power off. The ARS Server saves the information 
received in the Registration/Deregistration message and distributes the presence information to 
interested data applications. Once the presence information is received, the Data Applications can 
start the data communication with the SU. For the MOTOTRBO™ radio, the data message can be 
Text Message, Telemetry, Location or any User Customized data. 

When a Data Application wishes to learn about presence information of some Subscribers, it sends a 
SUBSCRIBE to the ARS Server. This request identifies the desired SU by its ID or any other key 
attribute. The ARS Server sends an immediate NOTIFY message containing the state of the SU to 
the Data Application. 

Figure 1 is just an example of the ARS architecture. The purpose of this document is to publish the 
ARS protocol to a third party developer to develop their own ARS Server. This document covers the 
registration communication between the MOTOTRBO™ radio and the ARS Server. The developer is 
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responsible for implementing the communication between ARS Server and their Data Applications. 
Please see the reference [1], [2] and [3], in section 1.6, for more information. 

2.2 Relationship between ARS Server and DDMS 

The DDMS (Device Discovery and Mobility Service) is an ARS Server developed by Motorola 
Solutions. It is used in a MOTOTRBO™ system to monitor the presence/mobility information of ARS- 
capable subscriber units and report their state to interested applications. It exposes two 
communication interfaces, one towards the Radio Network Infrastructure (RNI), known as the SU 
Interface, and the other one towards the subscribing applications, known as the Watcher Interface. 
The SU Interface allows the DDMS to exchange ARS messages with the subscriber units over the 
UDP/IP protocol, while the Watcher Interface enables the communication between the DDMS and the 
Watcher applications over the UDP/IP and TCP/IP protocols. Its architecture is similar with what is 
shown in Figure 2-1 . 

The DDMS is a Windows-based application. If a third party application utilizes a different operating 
system, this ARS protocol specification allows a developer to develop their own ARS server. Note 
that if the developer wants to develop their own ARS server in the Windows operating system, the 
ARS server can co-exist with the DDMS application in condition that DDMS works in Passive Mode. 
For details, refer to DDMS help file. Pay attention that if MNIS (MOTOTRBO Network Interface 
Service) is deployed in the repeater system, the DDMS is MUST installed. MNIS is also called IP 
Wireline Data Gateway, it also has watcher interface. MNIS requires Motorola DDMS to receive 
routing parameters and uses it to send the data to the destination radio. For details, refer to [5]. 

The ARS Server should provide two communication interfaces: 

1 . Interface between Registration application in SU and ARS Server 

Upon power on, roaming to another site, switching the SU application to a data capable mode 
and periodically, the Registration application in SU sends a registration message to its ARS 
Server. It also sends a deregistration message upon power off. The ARS Server acknowledges 
the registration messages. 

Upon power on, the ARS Server sends a query message to a SU whose registration is not 
expired. 

2. Interface between Data application and ARS Server 

A Data application should subscribe for the presence/absence event of all the SUs of its 
interest. When one of those SUs changes to presence status, the ARS Server sends a 
notification to the Data application. 
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Note: This interface is only needed when the ARS Server is designed as an individual 
application. The functionality of ARS may be incorporated into the third party data application, 
and therefore this interface is not needed. 

2.3 Automatic Registration Service Procedures 

This section presents the Automatic Registration Service procedures. This is accomplished via a 
series of scenarios presented as Message Sequence Charts. 

2.3.1 SU Powers On 

This scenario illustrates how a mobile subscriber registers with the ARS Server upon power on. A 
subscriber with Device ID of 1 1 is used as an example. 




Figure 2-2 - ARS Power On 

Upon power up, the SU examines the configuration of the current mode. If the SU is packet data 
capable and the ARS feature is enabled, the SU will form an ARS Registration message and send it 
to the ARS Server. To ensure it is ready for transmitting, the SU will wait random seconds (from 5 to 
15) to send out the ARS Registration message after power on. 

If the ARS Server does not respond within the ARS Reg Response Time, another ARS Registration 
Message will be formed and sent to the ARS server after random period. The random period is 
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between 49 seconds and 91 seconds, determined when radio power up. This will continue for 5 
retries. If registration retries are exhausted, after 300 seconds, radio repeats the initial procedure. 

Upon reception of the ARS Reg Response, the SU will stop the retry timer and start an ARS Refresh 
Timer using the value provided by the server. The purpose of this timer is to trigger a registration 
renewal procedure, which is used to periodically reaffirm the existence of the radio on the system to 
the server. 



Upon reception of the ARS Registration message, the ARS Server will send back an 
acknowledgment message to the radio and start a SU Inactivity timer. The “SU Inactivity Time” is 
“Registration Refresh Time” plus a delay. The delay should be configurable in the ARS Server. The 
recommended value is 120 seconds. If the ARS Server fails to receive a registration message within 
the “SU Inactivity Time”, it shall change the status of the SU as “absent”. 



2.3.2 SU Update Registration Status 

This scenario illustrates how an SU periodically refreshes its registration status. This allows the ARS 
Server to clean up stale registration entries if necessary. A subscriber with Device ID of 1 1 is used as 
an example. 



su 



ARS 

Server 



1 

2 ARS Refresh Timer 

3 

4 

5 

6 

7 ARS Refresh Timer 



ARS Power UP 






ARS_Device_Reg 



00 07 F0 40 02 31 31 00 00 
ARS_Device_Reg 



00 07 F0 40 02 31 31 00 00 
ARS_Device_Reg_Ack 



00 02 BF 01 
ARS_Device_Reg_Ack 



00 02 BF 01 



->■ 



Figure 2-3 - ARS Registration Refresh 

When the ARS Refresh Timer expires, the SU forms an ARS Registration message and sends it to 
the ARS Server to update its present state. 

Upon reception of the registration message, the ARS Server will refresh the inactivity timer for the 
specific SU. 
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1 Upon reception of the registration response message, the SU will start the registration refresh timer. 

2 Note: If a registration response message is not received, the registration refresh timer in the SU will 

3 expire and another registration message will be sent. 

4 2.3.3 SU Device Deregistration 

5 This scenario illustrates how an SU will attempt deregister from the ARS server. 




6 

7 Figure 2-4 - ARS Device Deregistration 

8 When the SU is powering down and ARS is enabled in current personality, the SU forms a 

9 deregistration message and sends to the ARS server and continues the power down sequence (no 

10 confirmation required). 

1 1 Note: The Deregistration message is sent out at best effort, but not guarantee. 

1 2 Upon reception of the ARS deregistration message, the ARS server shall remove the SU entry from 

13 the database. 

14 Only on the condition when the SU is powering down on an ARS enabled personality, it will send out 

15 the ARS deregistration message. The radio will not send out the de-registration message when 

1 6 channel is changed or SU roam out of the site. 
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2.3.4 SU Query 

This scenario illustrates an ARS Server querying an SU to determine if it is still within range of the 
system and registered with the server. 




Figure 2-5 - ARS Query 

Upon power on, the ARS Server shall send a query message to each SU in its database whose 
registration has not expired. 

Upon reception of the ARS Query message, the SU shall send an acknowledgement message to the 
ARS Server. 

The ARS Server shall set the state of a SU to “absent” if it fails to receive an ACK for the query 
message sent to the SU within the Response time. The Response time should be configurable and is 
able to be optimized in the ARS Sever. The recommended Response time is 5 seconds. 

2.4 ARS Initialization Delay 

With ARS enabled, when a large amount of radios power on within a short period of time, many ARS 
messages collide no matter the ARS messages are sent on the selected channel in the MOTOTRBO 
conventional system or the Enhanced GPS Revert channel in the MOTOTRBO Capacity Plus system. 
This impacts the system usage for voice and data call during that time. 

Before MOTOTRBO R1 .7, the ARS message delay is between 5 seconds to 1 5 seconds. This delay 
is not large enough for avoid collision for the case that 5 radios power up at the same time. 
MOTOTRBO R1 .7 introduces the ARS Initialization Delay feature in the radio to randomize the delay 
of sending ARS registration message at power up so that different radios send out the ARS 
registration message at different time even though they power up at the same time. In CPS, the ARS 
Initialization Delay field configures the maximum value of the random delay. This configuration is 
radio wide. The same value shall be configured in all the radios in a system. Please see Reference 
[6] for more details on how to select the ARS Initialization Delay based on the number of radios, the 
voice profile and the system type. 
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With the delay of the ARS message, the application may use other messages coming from the radio 
as the presence indication, e.g. location update, or text message. If the application cannot tolerate the 
ARS message delay, it shall turn off the ARS Initialization Delay and reduce the number of the radios 
powering up at the same time. 

2.5 ARS Message Path 

The path of ARS registration message from the radio is different between the MOTOTRBO trunked 
system and the MOTOTRBO conventional system. In the MOTOTRBO conventional system, the ARS 
registration / deregistration message from the radio to the ARS server is always sent on the current 
selected channel no matter the GPS Revert channel or the Enhanced GPS Revert channel is 
selected or not. In the MOTOTRBO Capacity Plus Trunked system, the ARS registration message 
from the radio to the ARS server is sent on the Data Revert channel or the Enhanced GPS Revert 
channel depending on the current selected channel selects the Data Revert channel or the Enhanced 
GPS Revert channel. Due to the timing and power off sequence in the radio, the ARS deregistration 
message from the radio to the ARS server is always sent on the Data Revert channel no matter the 
current selected channel selects the Enhanced GPS Revert channel or not. 

See Reference [2] for more information on Data Revert channel, the Enhanced GPS Revert channel, 
and the GPS Revert channel. 

2.6 Sign In / Sign Out Service 

The Sign In/Sign Out feature is to ask the radio user to sign in/out from a job ticket management 
system with his/her sign-in ID which is ASCII code. It can also indicate the current state that the user 
has signed into the system or not. The radio performs different behaviors in different states. E.g. 
Handle Job Ticket according to Signed In or Not Signed In state. The sign-in information shall be kept 
until radio power down or user sign out manually. The sign-in menu will only be available in digital 
channel when Sign In/Sign Out Enabled field checked by CPS. For CPS details, refer to section 4.2 
ARS Radio ID and ARS Monitoring ID 

The “ARS Radio ID” and “ARS Monitoring ID” are both ARS related fields but for different purposes. If 
there is only one ARS server in the system, the ARS Monitor ID shall not be set in the control station 
nor in any of the field radios. Configuring the ARS Monitor ID in the field radios will cause the flooding 
of the ARS messages in the system. For details, refer to [7], 

The “ARS Radio ID” is the ID of the radio that is connected to the ARS server that the user intends to 
communicate with for data services. 
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Figure 4-2 - ARS Radio ID 

The “ARS Monitoring ID” is the ID of the radio that is connected to the ARS server that the user 
intends to communicate with for the Over-the-Air Programming (OTAP) services. If the ARS Monitor 
ID is configured in the control station, the control station will not send the layer 2 confirmation for the 
ARS message, however it will still pass the ARS message to the connected server. The connected 
server interfacing to the control station shall not send the layer 7 ARS message acknowledgement. 
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Figure 4-3 - ARS Monitoring ID 
Sign In / Sign Out Enable. 

If the user signs-in successfully, the sign out will be shown in main menu instead. The Sign In/ Sign 
Out state messages are sent from radio to ARS server and follow the standard protocol of ARS User 
Registration/Deregistration Message. For details, refer to section 3.4.7 ARS User Registration 
Message - section 3.4.11 ARS User Deregistration Acknowledgement. 

DDMS is responsible to acknowledge the radio sign-in/out message in this feature. When DDMS 
receive the sign in request from subscriber, it needs to verify if the user ID in the login request is a 
valid user or not. Thus DDMS will send an authentication request message to authentication server 
which is a separate application to validate the user ID. The Authentication Server is required to send 
back the Authentication Reply Message after checking the user ID in its database. All the 3 rd party 
applications who interested the radio user Sign in/Sign Out state need subscribe Sign In/Sign Out 
messages first, which is the same as Interface between Data application and ARS Server in section 
2.2. For DDMS to Watcher Interface and MSCs in detail, refer to [5]. 
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Figure 2-6 - Sign In / Sign Out Using the DDMS 
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3 Protocol Definition 
3.1 PDU Structure 

The ARS PDUs consist of a common header structure followed by the ARS specific elements. The 
basic structure of all ARS PDUs is shown in the following figure. 



i 1 r 

Message Size 

J I L 



t 1 r 

1st Header 

J I L 



1 1 1 

Subsequent Header(s) 

I I I 



i 1 r 

Payload 

J I L 



CSBK Capability(0x1080) 



Inclusion 


Size 


Required 


2 Bytes 


Required 


1 Byte 


Optional 


Varies 


Optional 


Varies 


Optional 


2Bytes 



Figure 3-1 - ARS Protocol Message Structure 

The fields are defined as follows: 

• Message Size (Always Present) - This indicates the number of bytes to follow. The size 
DOES NOT include the two Message Size bytes. 

• First Header (Always Present) - This header includes basic information such as the PDU 
type. 

• Subsequent Header(s) (Depends on PDU Type) - Includes additional information specific to 
the PDU Type. 

• Payload (Depends on PDU Type) - This includes any PDU specific payload information. 
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3.2 Header Bit Definitions 

The following figure shows the bit definition in each box of the header. 
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Figure 3-2 - 1 st Header Bit Definitions 

The setting of each bit shall depend on different application scenarios. The following shall describe 
their functionalities of each bit at different conditions. 

1 . Header Byte 1 (Always Present) 

• Extension Bit (Ext) - If this bit is set, there are additional or optional header byte(s) that 
further define the message. 

o Required headers are not specified by the use of this bit but are implied in the definition 
of the PDU. 

o If the use of an optional header is required, the PDU must include all optional headers 
that occur before that header. 

• Acknowledgement Required / Acknowledgement Failure (Ack) - The use of this bit 
depends upon the PDU itself. For the purposes of this bit, the PDU is considered an 
acknowledgement PDU or a non-acknowledgement PDU. 

o Non-Acknowledgement PDU - If this bit is set, it indicates that the initiator is requesting 
an acknowledgement to this PDU. 

o Acknowledgement PDU - If this bit is clear, this acknowledge indicates a success of the 
respective request. If this bit is set, this acknowledgement indicates the failure of the 
request. 

• Priority - This bit indicate the relative priority of the PDU. 
o 1 is high, 0 is normal. 

o In general, all control PDUs are high priority. 

• Control/User Bit (Cntl) - If this bit is set, it indicates that this is a control message for the 
protocol. The protocol layer uses control messages to exchange information with its peer. If 
this bit is clear, this is user data. For example, text message. 

• PDU Type - Defines the PDU Type. Types are associated with the control/user setting. For 
example, there may be a PDU Type 0 for control and a PDU Type 0 for user data. 

2. Header Byte X (Optional, X>1 , Dependent on Ext setting of byte X-1 ) 

• Extension Bit (Ext) - If this bit is set, there is another optional byte that follows which further 
defines the type. This means, the 2nd byte which defines header byte shall follow the 
extension. 
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Notes: 



• The Address field is not used for the ARS protocol messages, so the Address Size field is 
always set to 0. 

• Header extension bytes that are optional must follow the defined order. If optional header byte 
(3) is required, then header byte (2) must be present. 

• If a generic failure is received, for example an acknowledgement with the Acknowledgement 
Failure bit set, and optional extension headers were included, the initiator of the message may 
retry the message without the use of extension headers. This will act as a “lowest common 
denominator” for the protocol. 

• Any PDU types that are not understood should be ignored. 



3.3 CSBK Capability Definition 

The following figure shows the bit definition in CSBK Capability Fields. 

Required 
in CSBK ARS 



Required .. . 

\/arpQ 
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=1 


1 1 1 1 1 1 

Reserved 
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Figure 3-3 - CSBK Capability Structure 

The CSBK ARS feature is applicable when using the CSBK data feature. CSBK Capability Fields are 
only available when the CSBK data feature is enabled in CPS. For details, refer to [4], 

CSBK ARS message has the same message sequences and same message format with 2 extra 
bytes (0x1080) appended to the end of message in contrast to standard ARS messages. 
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1 3.4 ARS Protocol Messages 

2 This section defines the ARS protocol messages. The ARS protocol does not define any user 

3 messages. 

4 3.4.1 ARS Device Registration Message 

5 This message is used to register a device with the ARS server. 

6 1. Headers 

7 • First Header Byte (Required) 



Bit(s) 


Field 


Value 


Notes 


7 


Extension 


Varies 


Set to 1 if the second header is present 


6 


Acknowledgement 


1 


Set to 1 to request acknowledgement 


5 


Priority 


1 


Set to 1 to indicate high priority 


4 


Control/User 


1 


Set to 1 to indicate Control message type 


3-0 


PDU Type 


0000 


Type code for this message 



9 • Second Header Byte (Optional) 

1 0 The second header specifies the encoding of the non-size portions of the payload. If the 

1 1 second header is not present, the encoding is UTF8. 



Bit(s) 


Field 


Value 


Notes 


7 


Extension 


0 


Clear to 0, no other optional headers to 
follow 


6-5 


Event 


Varies 


Further qualifies the registration. 

• 0x01 - Initial Event 

• 0x1 0 - Refresh Event 


4-0 


Encoding 


00000 


Indicates the encoding of the non-size 
portions of the payload (name field). 

• %00000 (UTF8) 



12 

13 2. Payload 

14 The payload of the registration message contains the name field. The field is Length-Value 

1 5 encoded. If a particular portion of the name field is not used, the associated length should be 

16 set to zero. 

1 7 The format of the name field is as follows: 
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7 6 5 4 3 2 1 0 




Inclusion Size 

Required 1 Octet 



Required Varies 



Required 1 Octet 



Optional Varies 



Required 1 Octet 



Optional Varies 



Figure 3-4 - ARS Protocol Message Structure for Name Field 

The size indicates the number of characters based on the encoding scheme. The Device Identifier 
field is set as the SU ID. The User Identifier and Password fields are not used, so the User Identifier 
Size and Password Size fields are set to 0. For example, for a SU with ID of 1 1 , the payload data is 
0x02 0x31 0x31 0x00 0x00. 

3.4.2 ARS Device Registration Acknowledgement (Success) 

This message is used to positively acknowledge an ARS device registration message. Optional 
headers are used to convey the Refresh Timer value and the Session Timer value to be used by the 
subscriber. 

1. Headers 

• First Byte (Required) 



Bit(s) 


Field 


Value 


Notes 


7 


Extension 


Varies 


Set to 1 if the second header is present 


6 


Acknowledgement 


0 


Clear to 0 to indicate successful ACK 


5 


Priority 


1 


Set to 1 to indicate high priority 


4 


Control/User 


1 


Set to 1 to indicate Control message type 


3-0 


PDU Type 


1111 


Type code for this message 
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• Second Byte (Optional) 

The second header specifies the refresh timer value to be used by the subscriber. If this 
header is not present, then the subscriber must use a refresh time value of zero (disabled). 



Bit(s) 


Field 


Value 


Notes 


7 


Extension 


0 


Clear to 0, no other optional headers to 
follow 


6-0 


Refresh Time 


Varies 


• 1 unit == 30 mins 

• Default: 0 == disabled, no refresh 
required 

• Range: [%1, %1 111111] , 30minsto 
approx. 2.5 days 



2. Payload 
None. 

3.4.3 ARS Device Registration Acknowledgement (Failure) 

This message is used to negatively acknowledge an ARS device registration message. An optional 
header is used to convey the reason for the failure. 

1. Headers 

• First Byte (Required) 



Bit(s) 


Field 


Value 


Notes 


7 


Extension 


Varies 


Set to 1 if the second header is present 


6 


Acknowledgement 


1 


Set to 1 to indicate a failed ACK 


5 


Priority 


1 


Set to 1 to indicate high priority 


4 


Control/User 


1 


Set to 1 to indicate Control message type 


3-0 


PDU Type 


1111 


Type code for this message 



• Second Byte (Optional) 

The second header specifies additional information to further qualify the failure. 



Bit(s) 


Field 


Value 


Notes 


7 


Extension 


0 


Clear to 0, no other optional headers to 
follow 


6-0 


Failure Reason 


Varies 


%0000000 - Device not authorized for 
service. 
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2. Payload 
None. 

3.4.4 ARS Device Deregistration Message 

This message is used to deregister a device from the ARS server. Note that if the device is 
deregistered from the ARS Server, the user is also deregistered from the ARS Server. 

1. Headers 

• First Byte (Required) 



Bit(s) 


Field 


Value 


Notes 


7 


Extension 


0 


Clear to 0, no other optional header to 
follow 


6 


Acknowledgement 


0 


Clear to 0, no acknowledgement required 


5 


Priority 


1 


Set to 1 to indicate high priority 


4 


Control/User 


1 


Set to 1 to indicate Control message type 


3-0 


PDU Type 


0001 


Type code for this message 



2. Payload 
None. 

3.4.5 ARS Query Message 

This message is used to query a specific subscriber. If the subscriber is ARS registered, it will 
respond with a simple acknowledgement. 

1. Headers 

• First Byte (Required) 



Blt(s) 


Field 


Value 


Notes 


7 


Extension 


0 


Clear to 0, no other optional header to follow 


6 


Acknowledgement 


1 


Set to 1 to request acknowledgement 


5 


Priority 


1 


Set to 1 to indicate high priority 


4 


Control/User 


1 


Set to 1 to indicate Control message type 


3-0 


PDU Type 


0100 


Type code for this message 



2. Payload 
None. 
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3.4.6 ARS Query Acknowledgement 

This is a simple header used to respond to a query request. 

1. Headers 

First Byte (Required) 



Bit(s) 


Field 


Value 


Notes 


7 


Extension 


0 


Clear to 0, no other optional header to 
follow 


6 


Acknowledgement 


0 


Clear to 0 to indicate successful ACK 


5 


Priority 


1 


Set to 1 to indicate high priority 


4 


Control/User 


1 


Set to 1 to indicate Control message type 


3-0 


PDU Type 


1111 


Type code for this message 



2. Payload 
None. 

3.4.7 ARS User Registration Message 

This message is used to register a user with the ARS server. 

1. Headers 

• First Header Byte (Required) 



Bit(s) 


Field 


Value 


Notes 


7 


Extension 


Varies 


Set to 1 if the second header is present 


6 


Acknowledgement 


1 


Set to 1 to request acknowledgement 


5 


Priority 


1 


Set to 1 to indicate high priority 


4 


Control/User 


1 


Set to 1 to indicate Control message type 


3-0 


PDU Type 


0101 


Type code for this message 



MOTOROLA 



Motorola Solutions Confidential Restricted 



Page 3-8 





1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 



MOTOTRBO 

Application Developer Program 



Automatic Registration Service 



• Second Header Byte (Optional) 

The second header specifies the encoding of the non-size portions of the payload. If the 
second header is not present, the encoding is UTF8. 



Bit(s) 


Field 


Value 


Notes 


7 


Extension 


0 


Clear to 0, no other optional headers to 
follow 


6-5 


Event 


XX 


Don’t care 


4-0 


Encoding 


00000 


Indicates the encoding of the non-size 
portions of the payload (name field). 

• %00000 (UTF8) 



2. Payload 

The payload of the registration message contains the name field. The field is Length-Value 
encoded. If a particular portion of the name field is not used, the associated length should be 
set to zero. 

The format of the name field is as follows: 







i 1 I 1 1 

Device Identifier Size 

i i i i i 












1 1 1 1 1 

Device Identifier 

i i i i i 












1 1 1 1 1 

User Identifier Size 

i i i i i 












1 1 1 1 1 

User Identifier 

i i i i i 












1 i 1 1 1 

Password Size 

l l 1 1 1 



~\ 1 r 

Password 

J I L 



Inclusion 


Size 


Required 


1 Octet 


Required 


Varies 


Required 


1 Octet 


Required 


Varies 


Required 


1 Octet 


Optional 


Varies 



Figure 3-5 - ARS Protocol Structure for Name Field 
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• Example 

The radio ID is 1 1 and the user ID is 999999999. 

Ox 00 1 0 F5 00 02 31 31 09 39 39 39 39 39 39 39 39 39 00 

3.4.8 ARS User Registration Acknowledgement (Success) 

This message is used to positively acknowledge an ARS user registration message. An optional 
header is used to convey the Session Timer value to be used by the subscriber. If the optional 
Session Timer header is not included, the user session will expire when the refresh timer expires. The 
message shall be fixed as Ox 00 02 B7 00. 

1. Headers 

• First Byte (Required) 



Bit(s) 


Field 


Value 


Notes 


7 


Extension 


Varies 


Set to 1 if the second header is present 


6 


Acknowledgement 


0 


Clear to 0 to indicate successful ACK 


5 


Priority 


1 


Set to 1 to indicate high priority 


4 


Control/User 


1 


Set to 1 to indicate Control message type 


3-0 


PDU Type 


0111 


Type code for this message 



• Second Byte (Optional) 

The second header specifies the refresh timer value to be used by the subscriber. If this 
header is not present, the subscriber should use a default refresh timer value of zero 
(disabled). 



Bit(s) 


Field 


Value 


Notes 


7 


Extension 


0 


Clear to 0, no other optional headers to 
follow 


6-0 


Session Time 


0000000 


0 means session is valid until radio is 
power cycled 



2. Payload 
None. 
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1 3.4.9 ARS User Registration Acknowledgement (Failure) 

2 This message is used to negatively acknowledge an ARS user registration message. An optional 

3 header is used to convey the reason for the failure. 

4 1. Headers 

5 • First Byte (Required) 



Bit(s) 


Field 


Value 


Notes 


7 


Extension 


Varies 


Set to 1 if the second header is present 


6 


Acknowledgement 


1 


Set to 1 to indicate a failed ACK 


5 


Priority 


1 


Set to 1 to indicate high priority 


4 


Control/User 


1 


Set to 1 to indicate Control message type 


3-0 


PDU Type 


0111 


Type code for this message 



7 • Second Byte (Optional) 

8 The second header specifies additional information to further qualify the failure. 



Bit(s) 


Field 


Value 


Notes 


7 


Extension 


0 


Clear to 0, no other optional headers to 
follow 


6-0 


Failure Reason 


Varies 


Failure Reason: 

• 0x01 - User Validation Failed - User ID is 
not valid 

• 0x02 - User Validation Timeout - DDMS 
did not receive response from the User 
Authentication App within 30s. 

• All other values are considered 
transmission failure 



10 2. Payload 

11 None. 
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3.4.10 ARS User Deregistration Message 

This message is used to deregister a user from the ARS server. Note that this message does not 
deregister the device from the ARS Server. 

1. Headers 

• First Byte (Required) 



Bit(s) 


Field 


Value 


Notes 


7 


Extension 


0 


Clear to 0, no other optional header to 
follow 


6 


Acknowledgement 


1 


Set to 1 to request acknowledgement 


5 


Priority 


1 


Set to 1 to indicate high priority 


4 


Control/User 


1 


Set to 1 to indicate Control message type 


3-0 


PDU Type 


0110 


Type code for this message 



2. Payload 
None. 

3.4.11 ARS User Deregistration Acknowledgement 

This message is used to positively acknowledge an ARS user deregistration message. 

1. Headers 

• First Byte (Required) 



Bit(s) 


Field 


Value 


Notes 


7 


Extension 


0 


Clear to 1 to indicate no second header 


6 


Acknowledgement 


0 


Clear to 0 to indicate successful ACK 


5 


Priority 


1 


Set to 1 to indicate high priority 


4 


Control/User 


1 


Set to 1 to indicate Control message type 


3-0 


PDU Type 


0111 


Type code for this message 



2. Payload 
None. 
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4 CPS Provisioning 
4.1 ARS Enable 

The “ARS Enable” is to indicate whether the ARS feature is enabled or not in a specific personality. It 
is a Personality-Wide configuration. If the ARS feature is “on system change”, it means when radio 
powers up on this personality or mode change to this personality, radio will initiate a device 
registration message to the ARS server. If the ARS feature is “on system/site change” and IP Site 
Connect is enabled at this channel, it means when radio powers up, roaming to another site on this 
personality or mode change to this personality, radio will initiate a device registration message to the 
ARS server. 

Note: The ARS feature is only available when the MOTOTRBO™ radio is operating in digital mode. 
For analog personality, this parameter is always disabled and not allowed to change the setting by 
CPS. 




Figure 4-1 - ARS Enable Configuration 
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1 4.2 ARS Radio ID and ARS Monitoring ID 

2 The “ARS Radio ID” and “ARS Monitoring ID” are both ARS related fields but for different purposes. If 

3 there is only one ARS server in the system, the ARS Monitor ID shall not be set in the control station 

4 nor in any of the field radios. Configuring the ARS Monitor ID in the field radios will cause the flooding 

5 of the ARS messages in the system. For details, refer to [7], 

6 The “ARS Radio ID” is the ID of the radio that is connected to the ARS server that the user intends to 

7 communicate with for data services. 




9 Figure 4-2 - ARS Radio ID 

1 0 The “ARS Monitoring ID” is the ID of the radio that is connected to the ARS server that the user 

1 1 intends to communicate with for the Over-the-Air Programming (OTAP) services. If the ARS Monitor 

12 ID is configured in the control station, the control station will not send the layer 2 confirmation for the 

13 ARS message, however it will still pass the ARS message to the connected server. The connected 

1 4 server interfacing to the control station shall not send the layer 7 ARS message acknowledgement. 
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2 Figure 4-3 - ARS Monitoring ID 

3 4.3 Sign In / Sign Out Enable 

4 The “Sign In / Sign Out Enable” is to indicate whether the Sign In / Sign Out feature is enabled or not 

5 in a radio wide configuration. This feature shows an indication whether the user has signed into the 

6 third-party server or not on the home screen of the radio. The sign-in information is kept until the radio 

7 powers down or the user signs out manually. 

8 Note: The Sign In / Sign Out feature is only available when the MOTOTRBO™ radio is operating in 

9 digital mode. This feature is independent with ARS enable in personality wide configuration. 
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| MOTOTRBO Customer Programming Software - [Job Ticket Template Example.ctb] 
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1® 
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* 




m 




Open 


Save 


Reports 


Delete 


Cut Copy 


Paste 


£ 



General Settings 



Top Microphone Battery Saver Alerts Over-the-Air Programming Lone Worker Power Up Password and Lock 
Front Programming Password Delete All 

AF Suppressor 
Noise Suppressor p" 



Sign In / Sign Out 






Test Mode W 
Codeplug Password 



Microphone 



Log In/Log Out 

This feature allows the user to log in or log out of a third-party server from the radio with the user's log-in ID. This feature shows an 
indication whether the user has logged into the third-party server or not on the home screen of the radio. The log-in information is kept 
until the radio powers down or the user logs out manually. The Log In/ Log Out message follows the standard protocol of ARS User 
Register/Deregister. 



"3 






General Settings 



Expert View 



Figure 4-4 - Sign In / Sign Out Enable Configuration 
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1 4.4 IP and UDP Configuration 

2 The transport layer between MOTOTRBO™ radio and the ARS Server is UDP/IP. So we shall 

3 configure the IP address and UDP port for both MOTOTRBO™ radio and the ARS Server. The figure 

4 below shows the communication between the SU and ARS Server. 



PC ARS Radio Remote Radio 




5 

6 Figure 4-5 - Communication between the SU and ARS Server 

7 The ARS Server communicates with the remote radio via the ARS Radio, so there are two IP network 

8 segments. One is PC to ARS Radio segment and the other is ARS Radio to Remote Radio segment. 

9 Private IP address is used in the PC to ARS Radio network segment, or generally it is 1 92.1 68.1 0.x. 

1 0 This private IP address is transparent to the remote radio because the ARS Radio will do network 

1 1 address translation for the message that is sent to remote radio by PC. 

12 4.4.1 Radio IP Address 

1 3 The Radio has two IP addresses, one is for the CAI radio network, and the other is for the private 

14 radio network (PC network). Both the IP addresses can be configured by CPS. 

15 To configure the private radio network IP address, set the Radio IP field via CPS. For example, in 

16 Figure 10, it is set as 192.168.10.1. 

17 The CAI radio network IP address consists of two parts: the CAI Network ID and the Radio ID. The 

1 8 Network ID is the “Network ID” of the IP address of a radio and the Subscriber ID is the “Host 

1 9 Number” of the IP address of a radio. For example, in Figure 1 0, the CAI Network is 1 2 and the Radio 

20 ID is 1 0, then the IP address of the radio is 1 2.0.0. 1 0. If you want to know more detail about the 

21 Radio IP address derivation, please refer to reference [4] in section 1 .6. 

22 When the remote radio sends an ARS message to the ARS Server, the CAI radio network IP address 

23 is used as the source IP address of the message. 

24 4.4.2 4.2.2 Radio ARS UDP Port 

25 The Radio ARS UDP Port is always 4005 and is not CPS configurable. 
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4.4.3 ARS Server IP Address 

The ARS server running on a PC is connected to the ARS Radio. Based on the IP address 
assignment schema, the PC as the radio's accessory will have the same Host Number of the ARS 
Radio, and its Network ID is the Network ID of the ARS Radio + 1 . So the ARS Radio ID has to be 
configured. In the figure below, the CAI network ID is 1 2 and the ARS Radio ID is 1 1 , so the ARS IP 
is 13.0.0.11. Please see reference [4], in section 1.6, for more detail on the IP address assignment 
schema. 




Figure 4-6 - Radio and Server IP Address Configuration 

According to the configuration in Figure 10, when the remote radio sends an ARS message to the 
ARS Server, the source IP address is 12.0.0.10, and the destination IP address is 13.0.0.1 1 . And 
when the ARS Radio receives this ARS message, it will translate the destination IP address as the 
private IP address, for example 192.168.10.2, and then forward it to the ARS Server. 
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4.4.4 ARS Server UDP Port 

The Automatic Registration Service (ARS) UDP Port specifies a dedicated port number for the ARS 
Server to enable communication between the ARS client and ARS server. 




Figure 4-7 - ARS Server UDP Port Configuration 
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